In recent years, MPLS (Multi-Protocol Label Switching) that manages network paths by applying label switching to IP (Internet Protocol) networks has come into wide use, and GMPLS (Generalized Multi-Protocol Label Switching) which can be applied not only to IP networks, but also to TDM (Time Division Multiplexing) networks such as SDH (Synchronous Digital Hierarchy)/SONET (Synchronous Optical NETwork) and other networks such as wavelength switched networks, has been commercially implemented. The description given herein deals with a communication network and node apparatus in which paths are set up by using GMPLS, but the invention is not limited to this particular example but can be applied widely to any communication network and node apparatus in which paths are set up by label switching.
FIG. 1 shows a sequence illustrating a path generation (signaling) process for generating a path from the start point node N1 (ingress) of the path to the endpoint node N4 (egress) by using GMPLS. First, the node N1 transmits a path message “PathMsg”, i.e., a reservation request message for requesting the reservation of a path setup, to its adjacent intermediate node N2 via a supervisory channel by specifying ERO (Explicit_Route Object), which is information specifying a route up to the endpoint node N4, and a label that the node N1 intends to use between it and the adjacent node N2.
At the node N2, if the label specified by the received PathMsg is not in use, the label is set to a reserved state, and the node N2 forwards the same PathMsg to the next intermediate node N3. The node N3 performs the same processing as the node N2, and forward the PathMsg to the endpoint node N4.
Then, at the node N4, if the path requested by the received PathMsg can be set up, the node N4 returns a reserve message “ResvMsg”. The reserve message corresponds to a reservation completed message delivered to notify that the reservation of the path requested by the PathMsg is completed. The ResvMsg is transmitted via the supervisory channel, and after the transmission, the node N4 sets up its own cross connect in order to generate (open) the requested path. The node N3 that received the ResvMsg from the node N4 sets up its own cross connect and forwards the ResvMsg to the node N2. The same processing is performed at the nodes N2 and N1, and the path setup between the node N1 and the node N4 is completed.
FIG. 2 is a diagram showing the data structure of the PathMsg. In the figure, the hatched fields (objects) are required objects, and the others are optional objects. This convention also applies to the data structures hereinafter shown in FIGS. 3, 5, 12, and 26. A brief description of the data carried in the PathMsg is given below.
SESSION, SENDER_TEMPLATE: Fields for storing connection identification information, the connection being made uniquely identifiable by combining five kinds of information (ingress address, egress address, tunnel ID, LSP ID, and extended tunnel ID).
RSVP_HOP: Stores the local ID of the path message PathMsg transmitting node as identification information for the fiber used.
TIME_VALUES: A field for storing path refresh interval (the length of the refresh timer).
EXPLICIT_ROUTE: A field for storing routing information indicating how the connection is to be routed.
LABEL_REQUEST: A field for storing the type of the requested label.
PROTECTION: A field for storing the kind, etc. of the protection that the connection requests.
SESSION_ATTRIBUTE: A field for storing the name of the connection, etc.
ADMIN_STATUS: A field for storing special information such as Admin_Down and Deletion.
SENDER_TSPEC: A field for storing rate information (2.5G, 10G, etc.) that the connection requests.
UPSTREAM_LABEL: A field for storing the reserved label information (information for identifying wavelength).
ALARM_SPEC: A field for storing the kind and time of alarm generation.
NOTIFY_REQUEST: An object used to request the transmission of a NotifyMsg (to be described later) when a failure occurs on the requested path.
FIG. 3 is a diagram showing the data structure of the reserve message (ResvMsg). A brief description of the data carried in the ResvMsg is given below.
RESV_CONFIRM: A field for storing information used when requesting the transmission of a ResvConfMsg.
FLOWSPEC: A field for storing the same connection identification information as that stored in the SENDER_TEMPLATE object carried in the PathMsg.
FILTERSPEC: A field for storing requested rate information, as in the SENDER_TSPEC object carried in the PathMsg.
LABEL: A field for storing label information, as in the UPSTREAM_LABEL object carried in the PathMsg.
ALARM_SPEC: A field for storing the type and time of alarm generation.
NOTIFY_REQUEST: An object used to request the transmission of the NotifyMsg (to be described later) when a failure occurs on the requested path.
If a failure occurs on the path set up by GMPLS, notification of the occurrence of the failure and control for switching can be accomplished by transmitting the hereinafter described failure notification message “NotifyMsg” to the node requesting the transmission of the failure notification among the nodes located along the end-to-end path. Further, by using the ALARM_SPEC object, each node located along the end-to-end path can be notified of the occurrence of the failure. FIG. 4 is a sequence diagram showing how a node that detected the occurrence of a failure transmits the NotifyMsg.
When a failure occurs on the path set up by GMPLS, the node N3 that detected the failure transmits the NotifyMsg indicating the occurrence of the failure on the path, to the node (in the illustrated example, the start point node N1) that requested the NotifyMsg by using the NOTIFY_REQUEST object. The start point node N1 that received the NotifyMsg performs processing such as failure recovery (switching), for example, by setting up a path along a new route (a protection path) so as to circumvent the location of the failure.
FIG. 5 is a diagram showing the data structure of the NotifyMsg. A brief description of the data carried in the NotifyMsg is given below.
ERROR_SPEC: A field for storing information concerning the location of the failure.
The NotifyMsg also carries the SESSION and SENDER_TEMPLATE objects similar to the SESSION and SENDER_TEMPLATE objects carried in the PathMsg, and the path affected by the failure can be identified using these objects.
In the prior art, failure recovery has been accomplished in one of two ways, i.e., an alternate path (protection path) is computed upon detecting the occurrence of a failure, and the computed path is set up as the new path, or alternatively, the protection path is set up in advance, and upon detecting the occurrence of a failure, switching is made to the protection path.
Japanese Laid-open Patent Publication No. 2003-289325 discloses an alternate path design method for a communication network, in which a node that detected a failure forwards a failure notification message containing the failure location information to each of the other nodes, and the nodes that received the failure notification message switch the path in parallel fashion. In this alternate path design method, a first alternate path provided by the initial design is selected, failure notification time is computed for a node, among the nodes on the first alternate path, that requires the longest time to receive the notification from the failure detecting node, a search is made for a second alternate path that is different from the first alternate path, and the second alternate path is checked whether it can share reserve communication resources in the event of other failure; if this condition is satisfied, the longest failure notification time among the nodes on the second alternate path is compared with that on the first alternate path, and if the time required along the second alternate path is shorter, the alternate path is updated to the second alternate path, and the alternate path routing information in the database is updated accordingly.